1. Field of the Invention
The invention relates to Quality of Service (QoS) in packet switched communication systems. Admission control is applied for packet flows, which are transmitted using bearers. Particularly, the invention relates to a method for the mapping of packet flows to bearers in a communication system.
2. Description of the Related Art
The transport of voice and multimedia over packet switched networks has in the recent years emerged as a viable alternative for traditional circuit switched networks. In circuit switched networks resource allocation is based on the allocation of entire physical circuits or repeating timeslots within physical circuits for users. From an abstract point of view the transport technology relieves the network of the complexity involving admission control and Quality of Service (QoS) allocation. In packet switched networks the transport technology inherently does not provide the users with guarantees involving the QoS available for a single user. QoS is observed in terms of such properties as, for example, data rate, delay, the variation of delay and bit error probability. These properties are usually referred to as QoS parameters. The users must be guaranteed certain QoS parameters. However, other users must also be taken into consideration before granting given QoS parameters for a given new user. In other words, it must be ensured that the capacity of the system is not exceeded when implementing the new users QoS requirements in the system. The QoS guarantees already committed to must be sustained. It must be checked that the increase in the use of a variety of resources such as packet queues in network nodes, network node packet switching capacity and transmission line capacity does not cause a relaxation from already guaranteed parameters such as maximum delays and data rates.
In order to control the access of new users to network resources admission control is applied. In packet switched networks admission control entities have been introduced to control access to network resources. The admission control entities are interfaced by users or by network nodes on behalf of users in order to perform QoS allocation for users. Admission control may be performed in small scale for individual users or for flows originated by individual users. In larger scale admission control may be performed for entire networks at the edge of a large core network by determining that the networks adhere to predefined service level agreements. Examples of technologies for the implementation of QoS in Internet Protocol (IP) networks include Integrated Services (IntServ) and Differentiated Services (DiffServ) defined in the Internet Engineering Task Force (IETF) documents RFC 2210 and RFC 2475, respectively. Yet another standard for the QoS is the Multi Label Protocol Switching (MPLS) defined in IETF document RFC 3032. In the Common Open Policy Services (COPS) framework defined in the IETF document RFC 2753, the admission control decisions are centralized to a Policy Decision Point (PDP), which makes decisions whether to admit a certain flow or set of flows to the network on behalf of a Policy Enforcement Point (PEP). The PEP is in practice a router or a network edge node. When receiving an allocation request for a flow, the PEP contacts the PDP. The PDP returns a policy decision to the PEP, which in effect tells whether the flow should be admitted or denied. The QoS parameters may entirely be provided from the PDP or simply modified by the PDP. The information regarding a flow or a set of flows is obtained to a PEP, for example, via the Resource Reservation Protocol (RSVP) defined in the IETF document RFC 2205.
In the Universal Mobile Telecommunications System (UMTS) the Common Open Policy Services protocol defined in the IETF document RFC 2748 is used to determine QoS parameters for Packet Data Protocol (PDP) contexts based on at least one set of binding information provided from a Mobile Station (MS). Each such set of binding information consists of an authorization token and a number of flow identifiers. The authorization token provides the Fully Qualified Domain Name (FQDN) of a Policy Decision Point (PDP) and a unique session identifier within the PDP. The flow identifiers identify uniquely either a single IP flow or a bi-directional combination of two IP flows associated with the session.
Reference is now made to FIG. 1, which illustrates a Universal Mobile Telecommunications System (UMTS) in prior art. In FIG. 1 there is shown a mobile station 100, which communicates with a Radio Network Controller (RNC) 114 within a Radio Access Network 110. The communication occurs via a Base Transceiver Station (BTS) 112. The radio access network 110 is, for example, a 2G GSM/EDGE radio access network or a 3G UMTS radio access network. An IP Connectivity Access Network (IP-CAN) functionality (not shown) connected to access network 110 comprises at least a Serving GPRS Support Node (SGSN) 122 and a Gateway GPRS Support Node (GGSN) 124. The functionality of the IP-CAN is disclosed in the 3G Partnership Project specification 23.060. SGSN 122 performs all mobility management related tasks and communicates with a Home Subscriber Server (HSS) 160 in order to obtain subscriber information. GGSN 124 provides GPRS access points. There are access points, for example, to a Media Gateway (MGW) 126, to a first router 142 attached to an IP network 140 and to a Proxy Call State Control Function (P-CSCF) 152. The access point for P-CSCF 152 is used to convey signaling traffic. GGSN 124 establishes Packet Data Protocol (PDP) contexts, which are control records associated with a mobile subscriber such as mobile station 100. A PDP context provides an IP address for packets received from or sent to mobile station 100. A PDP context has also associated with it a UMTS bearer providing a certain QoS for mobile station 100. In GGSN 124 there is a primary PDP context for the signaling packets associated mobile station 100. For the user plane data packets carrying at least one IP flow there is established at least one secondary PDP context. The at least one IP flow is established between a calling terminal and a called terminal in association with an IP multimedia session. An IP flow carries a multimedia component such as a voice or a video stream in one direction. For voice calls at least two IP flows are required, one for the direction from the calling terminal to the called terminal and one for the reverse direction. In this case an IP flow is defined as a quintuple consisting of a source port, a source address, a destination address, a destination port and a protocol identifier.
The communication system illustrated in FIG. 1 comprises also the IP Multimedia Subsystem (IMS) functionality. The IMS is used to set-up multimedia sessions over IP-CAN. The network elements supporting IMS comprise at least one Proxy Call State Control Function (P-CSCF), at least one Inquiring Call State Control Function (I-CSCF), at least one Serving Call State Control Function S-CSCF, at least one Brakeout Gateway Control Function (BGCF) and at least one Media Gateway Control Function (MGCF). As part of the IMS there is also at least one Home Subscriber Server (HSS). Optionally, there is also at least one Application Server, which provides a variety of value-added services for mobile subscribers served by the IP multimedia subsystem (IMS). The IMS is disclosed in the 3G Partnership Project (3GPP) specification 23.228. P-CSCF 152 receives signaling plane packets from GGSN 124.
The P-CSCF usually comprises a Policy Decision Function (PDF), which corresponds to a Policy Decision Point (PDP) familiar from the COPS framework. The PDF may also be implemented as a separate PDP, which communicates with the P-CSCF. Without the authorization from the P-CSCF, a primary PDP context is opened in GGSN 124. Via the primary PDP context are sent signaling plane packets used to set-up a session between mobile station 100 and a called party terminal (TE) 146. In the signaling plane packets are carried Session Initiation Protocol (SIP) signaling messages. The Session Initiation Protocol (SIP) is disclosed in the Internet Engineering Task Force (IETF) document RFC 3261. The signaling message is processed by P-CSCF 152, which determines the correct serving network for the mobile station 100 that sent the signaling packet. The determination of the correct serving network is based on a home domain name provided from mobile station 100. Based on the home domain name is determined the correct I-CSCF, which in FIG. 1 is I-CSCF 154. I-CSCF 154 hides the topology of the serving network from the networks, in which mobile station 100 happens to be roaming. I-CSCF 154 takes contact to home subscriber server 160, which returns the name of the S-CSCF, which is used to determine the address of S-CSCF 156 to which the mobile station 100 is to be registered. If I-CSCF 156 must select a new S-CSCF for mobile station 100, home subscriber server 160 returns required S-CSCF capabilities for S-CSCF selection. Upon receiving a registration, S-CSCF 156 obtains information pertaining to mobile station 100 from HSS 160. The information returned from HSS 160 may comprise trigger information that is used as criterion for notifying an application server 162. Application server 162 may be notified on events relating to incoming registrations or incoming session initiations. Application server 162 communicates with S-CSCF 156 using the ISC-interface. The acronym ISC stands for IP multimedia subsystem Service Control interface. The ISC interface is disclosed in the 3GPP specification 23.228. The protocol used on ISC interface is SIP. AS 162 may alter SIP invite message contents that it receives from S-CSCF 156. The modified SIP invite message is returned back to S-CSCF 156.
If the session to be initiated is targeted to a PSTN subscriber or a circuit switched network subscriber, the SIP invite message is forwarded to a BGCF 158. BGCF 158 determines the network in which interworking to PSTN or the circuit switched network should be performed. In case PSTN interworking is to be performed in the current network, the SIP invite message is forwarded to MGCF 159 from BGCF 158. MGCF 159 communicates with MGW 126. The user plane packets carrying a media bearer or a number of interrelated media bearers for the session are routed from GGSN 124 to MGW 126 as illustrated in FIG. 1.
If the session to be initiated is targeted to terminal 146, which is a pure IP terminal, S-CSCF 156 forwards the SIP Invite message to terminal 146. Terminal 146 communicates with a second router 144, which interfaces IP network 140. IP network 140 is used to carry the user plane IP flows associated with the session established between mobile station 100 and terminal 146. The user plane IP flows between first router 142 and GGSN 124 are illustrated with line 128. The user plane IP flows between second router 144 and terminal 146 are illustrated with line 148.
In order to allocate the end-to-end QoS required for the user plane IP flows between mobile station 100 and terminal 146, the GGSN 124 provides to a PDF within P-CSCF 152 at least one set of binding information provided from a mobile station 100. The sets of binding information have been formed in the PDF within P-CSCF 152 in response to SIP signaling and the Session Description Protocol (SDP) definitions carried in the SIP signaling messages. In order to form a set of binding information, the PDF has allocated a unique identifier for a session to be established and has assigned unique flow identifiers for each IP flow or each bi-directional combination of two IP flows observed in the SDP definitions. The unique identifier together with the PDF FQDN is used to form an authorization token for the session in the PDF. The authorization token is returned to mobile station 100 as binding information. There may be other authorization tokens for other parallel sessions. Mobile station 100 also assigns unique flow identifiers for each IP flow or each bi-directional combination of two IP flows observed in the SDP definitions in the same way as the PDF.
The mobile station 100 sends the binding information, that is to say, the authorization token and the flow identifiers of the IP flows or bi-directional IP flow combinations to be set up, to the GGSN 124 upon the secondary PDP context establishment. The GGSN 124 sends the binding information to the PDF in an authorization request. In response to the sets of binding information, the PDF returns the QoS information for the IP flows identified in the sets of binding information. The QoS information is used to establish a UMTS bearer between GGSN 124 and mobile station 100. The QoS information is also used to establish an external bearer between GGSN 124 and terminal 146. The UMTS bearer is established using signaling towards SGSN 122 and from there to RNC 114. The UMTS bearer comprises a radio access bearer and a core network bearer. The external bearer is established from GGSN 124 either explicitly using RSVP signaling or implicitly by assigning the user plane packets associated with an IP flow a certain Differentiated Service Code Point (DSCP).
Reference is now made to FIG. 2, which illustrates a binding mechanism in association with the QoS authorization for Packet Data Protocol (PDP) contexts in prior art. In FIG. 2 there is illustrated a mobile station 100 and a GGSN 124. There is also a P-CSCF 152 and a PDF 220. The PDF 220 may be part of P-CSCF 152. Within mobile station 100 there is a SIP client entity 208. SIP client entity 208 takes care of all SIP signaling related tasks. It establishes a SIP session between mobile station 100 and a remote terminal (not shown). SIP signaling messages are exchanged between mobile station 100 and a remote terminal via P-CSCF 152. Within a SIP invite message and the associated response messages there is carried a Session Description Protocol (SDP) definition, which defines the properties of the media components that are part of the multimedia session. Each media components is represented in the packet traffic an IP flow or bi-directional combination of two IP flows. When the P-CSCF 152 receives a session description protocol definition, it checks the media components defined therein. It assigns flow identifiers to represent the media components. For the SIP session the P-CSCF 152 allocates a unique session identifier. The FQDN of P-CSCF 152 is combined together with the unique session identifier in order to determine an authorization token, which is returned from P-CSCF 152 to mobile station 100 in a SIP response message.
In mobile station 100 there is also an IP Bearer Service Manager 206. IP Bearer Service Manager 206 provides the IP level QoS parameters via a Translation/Mapping manager 204 to a UMTS Bearer Service Manager 202. In GGSN 124 there is also an IP Bearer Service Manager 216. IP Bearer Service Manager 216 provides the IP level QoS parameters to a UMTS Bearer Service Manager 212 via a Translation/Mapping Manager 214. There is also a Policy Enforcement Entity 218, which is a function within the GGSN 124. In FIG. 2 there are shown within GGSN 124 two packet data protocol contexts, namely PDP1 and PDPn. These packet data protocol contexts are secondary PDP contexts. In FIG. 2 there are at least four IP flows. There is a flow F11 and a flow F1p. There are also flows Fn1 and Fnm. The letter n indicates that theoretically there may be any integer number of secondary PDP contexts, which are active in GGSN 124 for mobile station 100. Associated with PDP1 there may be an integer number of flows numbered from 1 to p. Associated with PDPn there may be any integer number of flows numbered from 1 to m. In response to QoS parameters authorized by PDF 220, Translation/Mapping Manager 214 translates the authorized QoS parameters on IP level to UMTS Bearer Service Parameters. The IP level QoS parameters include at least maximum bit rate and maximum QoS class. UMTS Bearer Service Manager maps the maximum bit rate values for appropriate corresponding parameters for the Radio Bearer and for the Radio Access Bearer. Similarly, the QoS class is translated into a number of parameters, which define, for example, the allowed delay variation and bit error rate.
Reference is now made to FIG. 3, which illustrates Quality of Service (QoS) authorization signaling in prior art. In FIG. 3 there is a PDF 220, a GGSN 124, which comprises an IP Bearer Service Manager 216, a Translation/Mapping Manager 214 and a UMTS Bearer Service Manager 212. These functions are similar to the ones illustrated in association with FIG. 2. With GGSN 124 communicates a mobile station such as mobile station 100 (not shown). The starting point in FIG. 3 is that between a mobile station and a remote terminal there have been exchanged SIP signaling messages. The mobile station communicating with GGSN 124 has obtained binding information comprising at least two authorization tokens pertaining to two PDP contexts in signaling information. The authorization tokens are provided to mobile station from PDF 220 via a P-CSCF. As illustrated with arrow 301, the mobile station sends a PDP context activation request to GGSN 124. The PDP context activation comprises binding information, which consists of authorization token T1, flow identifiers F11 to F1p and QoS information. The QoS information comprises a traffic class and maximum bitrates for uplink and downlink directions as specified in 3GPP specification 24.008. In response to the PDP context activation, Policy Enforcement Point 216 sends the authorization token T1 and flow identifiers F11 to F1p in a COPS Authorization Request message to PDF 220, as illustrated with arrow 302.
In response to COPS Authorization Request message 302 PDF 220 provides a decision message comprising a COPS Install command to GGSN 124. The COPS Install command, which is generally used to authorize QoS, contains the policy information associated with IP flows F11 to F1p. The contents of the Install command are specified in the 3GPP specification 29.207. Associated with each secondary PDP context there are two unidirectional sets. A unidirectional set is provided for uplink and downlink directions separately. A unidirectional set comprises a direction indicator indicating uplink or downlink, a packet classifier and authorized QoS information. For each IP flow or a bundle of unidirectional IP flows there is a gate description and a gate status, that is, a packet handling action. The gate description comprises a packet classifier, in other words, a filter specification. The packet classifier includes a standard quintuple, which comprises a source IP address, a destination IP address, a source port, destination ports and a protocol identifier. The parameters of the packet classifier identify a sequence of packets associated with an IP flow or a bundle of unidirectional IP flows. The source and destination ports are described with a range consisting of a minimum and maximum value. If only one port is authorized, the minimum and maximum value of the range are identical. A filter specification describing more than one IP flow, that is, a bundle of unidirectional IP flows shall be only used in the case of identical protocol identifiers, IP addresses and successive port numbers. This occurs, for example, in the case of interrelated Real-Time Protocol (RTP) and Real-Time Control Protocol (RTCP) flows of a media component. The RTP and the RTCP are specified in the IETF document RFC 1889. For a bi-directional combination of two IP flows there are two gate descriptions, one for the uplink IP flow and one for the downlink IP flow. Separate from the unidirectional sets there is provided charging information for charging correlation between the IP-CAN and the IMS. The charging information is used to associate charging records generated from GGSN 124 to charging records generated in the IP multimedia subsystem side.
Authorized QoS information provides an upper bound on the resources that can be allocated for the combined set of IP flows, which are associated with the PDP context in the respective direction. The authorized QoS information contains a maximum QoS class and a data rate parameter. The maximum QoS class is used to identify the maximum allowed traffic class in UMTS. The packet handling action defines the packet handling that must be accorded to packets matching the packet classifier. The packet handling action results in the packets matching the classifier either being passed or silently discarded. Policy enforcement point 216 also verifies that the traffic class and maximum bitrate parameters provided in PDP context activation message 301 do not exceed the maximum QoS class or data rate parameters within the authorized QoS information. The traffic class and maximum bitrate parameters are specified in the 3GPP specification 24.008. Policy enforcement point 216 activates secondary PDP context PDP1 in response to the COPS Install command. PDP context PDP shall contain the flows F11 to flow F1p. PDP context activation is also acknowledged to the mobile station.
The mobile station activates also a second secondary PDP context as illustrated with arrow 305. The secondary PDP context activation contains authorization token Tn and associated flow identifiers Fn1 to Fnm. In response to the receiving of PDP context activation Policy Enforcement Point 216 sends an authorization request message to PDF 220, as illustrated with arrow 306. The request message contains a set of binding information. The set of binding information comprises authorization token Tn and flow identifiers Fn1 to Fnm. In response to the request message PDF 220 provides a decision message comprising a COPS Install command to GGSN 124 as illustrated with arrow 307. The install command provides gate descriptions comprising packet classifiers for each of the IP flows from Fn1 to Fnm. In response to the COPS Install command PDP context PDPn is activated within GGSN 124. PDP context PDPn shall contain the flows from Fn1 to Fnm. The PDP context activation is acknowledged to the mobile station.
The problem in prior art solutions is that it is limited to using a binding mechanism based on an authorization token and flow identifiers. Possible new binding mechanisms, which only support the providing of an IP Address or a user identity to a PDF, do not support the separation of the PDP contexts. If the same mobile station uses more than one secondary PDP context controlled by Service Based Local Policy (SBLP) disclosed in association with FIGS. 2 and 3, only the mobile station, in other words, a User Equipment (UE) knows, which flows are multiplexed in a given PDP context and which in other PDP contexts. This means that the PDF authorizing the sessions of the mobile station cannot authorize the relevant QoS values for each PDP context. The PDF can only authorize all sessions of the mobile station aggregately for all PDP contexts. In practice this means that all PDP contexts have as authorized values: As bit rate the sum of the bit rates of all sessions, as packet filters all filters of the sessions of the mobile station, as QoS class the maximum class amongst the sessions of the mobile station.
This causes several practical problems. For example, the mobile station may exceed the authorized bitrate, which results in the waste of network resources and bandwidth. Further, downlink packets have to be sent through all SBLP controlled PDP contexts, because the network does not know which context the mobile station is using for given media flows, which results into the waste of resources and a risk of jamming the traffic channel. Further, the mobile station may exceed the QoS class in some PDP contexts, which also amounts to waste of network resources and bandwidth.